Skip to content
This repository has been archived by the owner on Jan 3, 2024. It is now read-only.

Improve ARM architecture detection: arm64 and armv7 #106

Merged
merged 1 commit into from
Mar 1, 2021
Merged

Improve ARM architecture detection: arm64 and armv7 #106

merged 1 commit into from
Mar 1, 2021

Conversation

pdcastro
Copy link
Contributor

@pdcastro pdcastro commented Oct 14, 2020

When running pkg in a Docker Desktop ARM-image container on an Intel laptop, using binfmt_misc / QEMU architecture emulation, /proc/cpuinfo reports the Intel processor rather than the emulated ARM processor. The existing architecture detection then fails. Also, the existing detection code does not support arm64 (e.g. the Raspberry Pi 4), reporting armv6 instead.

if (unameOut.includes('armv7')) return 'armv7';
return '';
}

Copy link
Contributor Author

@pdcastro pdcastro Oct 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was only after writing and testing the code that I realised that there is already an open PR on the same topic: #101

I'd say that this PR (#106) is a bit more robust / conservative and complete, because:

  • It falls back to the existing /proc/cpuinfo implementation if uname is not available (however unlikely). Note that spawnSync('uname', ['-a']) does not throw an Error if uname does not exist, but sets uname.error which the code detects.
  • uname -a is a bit more robust than uname -m (thinking of all different Unix kernels out there: BSD, Solaris, Linux, even perhaps macOS...), as it does not rely on a particular field or implementation of uname.
  • The detection is case insensitive.
  • It detects arm64 (e.g. Raspberry Pi 4) in addition to armv7 (e.g. Raspberry Pi 2/3). I've tested on both!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Close this PR so :)

Copy link
Contributor Author

@pdcastro pdcastro Oct 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, my writing was ambiguous (I've now edited it): I meant that this PR (#106) is better than the pre-existing one (#101). But I leave it for reviewers to decide whether they agree! :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh ok sorry I misunderstood the comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pdcastro I really appreciate your help here and the descriptive comment!

@robertsLando
Copy link
Contributor

robertsLando commented Oct 15, 2020 via email

@robertsLando
Copy link
Contributor

@leerob please consider merging this

Copy link
Member

@leerob leerob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much! We appreciate your contribution back. I will try my best to help review / merge PRs that haven't been looked at in awhile.

@leerob leerob merged commit eef90fe into vercel:master Mar 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants